Software breakpoints are typically implemented as assembly instructions embedded in a program. A given one of these assembly instructions when encountered in the program causes execution of the program to transfer to a debugger. As is well known, the use of designated breakpoints in conjunction with the debugger allows a programmer to inspect the state of the program in order to fix a problem or better understand program behavior.
In the case of a single conventional processor, a software breakpoint may be embedded in a program by overwriting an existing instruction at the desired breakpoint location with an assembly instruction in the form of a specified debug operation code, also referred to as an opcode. The overwritten instruction is stored by the debugger so that it may subsequently replace the inserted opcode upon resumption of normal operation, as will be described below. Examples of conventional debug opcodes include opcodes referred to as DEBUG, TRAP, etc. These debug opcodes generally vary depending on the processor.
After a given breakpoint is taken and the programmer is ready to continue with normal execution of the program, a two step process typically takes place. First, the debugger replaces the debug opcode with the previously-overwritten existing instruction, so that this instruction alone may be executed (or “stepped”). Then the debug opcode is restored at the desired breakpoint location so that the next time program execution reaches this point, another breakpoint will occur.
Many high performance processors include an instruction cache. An instruction cache enables the processor to store frequently accessed instructions in a fast local memory that adapts its contents to the executing program.
A multiprocessor system generally includes multiple processors each connected to a common bus. Also connected to the common bus is a shared main memory that stores instructions and data for use by the processors. In such a system, each of the processors will typically have its own instruction cache. These instruction caches are particularly important in multiprocessor systems in that the caches serve to significantly reduce the bus traffic associated with the instruction and data fetches of the multiple processors.
The conventional single-processor software breakpoints described above generally do not work in a multiprocessor system. More particularly, in a multiprocessor system, once a particular one of the processors has taken a software breakpoint, the corresponding actual instruction must be written to the shared memory so the stopped processor can subsequently fetch and execute it. However, while the actual instruction is in shared memory, the other processors may fetch and execute it, thus missing the breakpoint. Thus, in a shared-memory multiprocessor system, the programmer utilizing conventional single-processor software breakpoint techniques would be likely to observe erratic behavior, e.g., sometimes a given processor would stop at a software breakpoint and other times it would not.
Examples of known multiprocessor systems include the DSP 16410 and DSP 16270 shared-memory multiprocessor digital signal processors (DSPs) available from Agere Systems Inc. of Allentown, Pa., USA. Each of these systems includes two processors, denoted DSP0 and DSP1. These processors do not have instruction caches, but can execute from a common shared memory. Consider a case where a software breakpoint has been set in the shared memory and executed by DSP0. In order to resume normal execution after the breakpoint is taken, the actual instruction code at the breakpoint location should be placed in local memory that is private to DSP0. This enables DSP0 to execute the actual instruction without preventing DSP1 from hitting the desired breakpoint. Implementing multiprocessor software breakpoints on the DSP16410 or the DSP16270 therefore may require local instruction memory, which adds to the cost of the device. In addition, rebuilding the executable code so that the breakpoint debug opcode is moved to the address space corresponding to the local memory can be inconvenient and time consuming for the programmer. These and other similar problems arise in a wide variety of other conventional multiprocessor systems.
The above-cited U.S. patent application Ser. No. 10/072,529 provides improved techniques for implementing software breakpoints in shared-memory multiprocessor systems, so as to avoid one or more of the above-described problems. An illustrative arrangement described therein is more specifically directed to resuming from a common software breakpoint, that is, a software breakpoint for which all of the processors in the multiprocessor system stop. The software breakpoint is configured to ensure that a specified debug opcode or other breakpoint code can remain present in the main memory of the multiprocessor system at all times, such that all of the processors of the system will reliably fetch and execute that breakpoint code even if one or more of these processors are resuming execution from the breakpoint.
In certain multiprocessor systems, however, it may be desirable to stop one or more, but less than all, of the processors. This may occur, by way of example, in debugging an application which is configured to run continuously or has real-time processing constraints. In a typical multiprocessor system, software breakpoints may be intrusive to such non-stop or real-time applications. More particularly, if a software breakpoint is set in main memory, all of the processors may fetch and execute it, even though the breakpoint may not be intended for all of the processors. Each processor upon stopping at the breakpoint determines if it is an intended target of the breakpoint. If a given processor is a target of the breakpoint, it transfers control to the debugger, and if it is not a target of the breakpoint, it resumes execution. In either case, while the given processor was stopped it may have violated real-time processing constraints or other application requirements, thereby leading to a system failure. Even for a processor that is an intended target of the breakpoint, it may be preferable to minimize the amount of time that the processor is stopped. For example, the action on stopping may be to execute a debug script and then automatically resume execution.
This intrusiveness issue is in large part due to the fact that all of the processors are sharing the same main memory, and unfortunately is not adequately addressed by conventional usage of the above-noted instruction caches.
It is therefore apparent that, despite the considerable advances provided by the techniques described in the above-cited U.S. patent application Ser. No. 10/072,529, a need exists for further improvements in implementing cache-based software breakpoints for single-processor and multiprocessor systems, particularly for software breakpoints used in the above-noted non-stop or real-time processing applications.